分布式集群核心知识总结
一、主从职责划分
- 主节点：处理所有写请求，生成变更日志，向从节点同步数据
- 从节点：承接读请求（读写分离），保存副本（高可用），执行备份等重操作
- 同步策略：同步复制（强一致高延迟）→ 半同步 → 异步复制（高性能有丢失风险）
二、集群如何管理（两个独立层面）
应用层：中间件自己的主从选举、故障转移（Sentinel / Raft / Paxos）
基础设施层：节点跑在哪、怎么调度（K8S / 物理机 / 云托管）- K8S 擅长管无状态服务；管有状态中间件需要 Operator 模式
- 生产中有状态中间件（MySQL、Redis）通常直接用云托管服务，不放 K8S
三、有状态 vs 无状态
- 无状态：请求不依赖服务器保存的数据，可任意扩缩容（Spring Boot 服务）
- 有状态：数据持久保存在节点上，节点与数据强绑定（Redis、MySQL、Kafka）
- 核心原则：应用层保持无状态，状态下沉到存储层
四、应用无状态化的工程实践
| 场景 | 有状态做法（❌） | 无状态做法（✅） |
|---|---|---|
| 登录状态 | 服务器 Session | JWT Token |
| 缓存 | 本地 HashMap | Redis 共享缓存 |
| 文件 | 本地磁盘 | OSS / MinIO |
| 并发控制 | synchronized | Redisson 分布式锁 |
| 定时任务 | @Scheduled | XXL-Job |
五、中间件集群的数据处理
两种核心策略：
复制（Replication） — 解决高可用，每个节点存全量数据
- MySQL binlog 同步主从，Redis 主从异步复制
分片（Sharding） — 解决容量，数据拆分到不同节点
- Redis Cluster：CRC16(key) % 16384 路由到对应 slot
- MySQL：ShardingSphere 按字段取模路由到对应库
- Kafka：按 key 路由到固定 Partition
生产标配 = 分片 + 复制，每个分片再做副本备份
六、最关键的一条结论
单节点扩展为集群的数据迁移代价极高（尤其 MySQL），应提前按集群方案设计，而不是等数据量撑不住了再拆。